<html>
<head>
<title>html2ps/html2pdf interactive forms</title>
<link rel="stylesheet" type="text/css" medial="all" title="Default" href="css/help.css"/>
</head>
<body>
<h1>html2ps/pdf interactive forms</h1>
<a href="index.html">Back to table of contents</a>

<h2>Difference between forms in HTML and PDF</h2>
<p>I guess, if you use html2ps script, then you know how forms are defined in HTML and how form data is sent using the POST format. This script
tries to emulate the browser behavior as closely as possible; nevertheless, there's several important differences.

<h3>Field names are required</h3>
<p>In HMTL, you may write an INPUT tag without &quot;name&quot; attribute and get working interactive control; often, submit and reset buttons
are written this way. When using html2ps interactive forms, you <strong>must</strong> provide &quot;name&quot; attribute for all
controls which should be rendered interactive. If you don't do it, the control will be rendered as a graphic like "Interactive forms" options 
disabled.

<h3>Field names should be unique</h3>
<p>In HTML you usually <i>may</i> enter several controls with the same name into the same form and get 
some kind of results. PDF files do not allow such fields at all. In this case, all subsequent fields 
sharing the same name will be rendered as non-interactive.
</p>

<h3>Form &amp field names</h3>
<p>Unlike HTML, the parameter names in POST request are not the field names. Acrobat Reader uses a &quot;fully qualified field names&quot;
instead. It means that field is identified by composite string having the form
<pre class="code">
&lt;form name&gt;.&lt;field name&gt;
</pre> 
(See also <em>PDF Reference 1.6 Fifth Edition, pp.638&ndash;639</em> 
for more precise and detailed explanation). When posting data in POST format, dots are converted to underscores, so you would get:
<pre class="code">
&lt;form name&gt;_&lt;field name&gt;
</pre> 
when processing the POSTed data.
</p>

<p>To illustrate what I've said above, consider the following example:
<pre class="code">
&lt;form name=&quot;form1&quot;&gt;
&lt;input type=&quot;text&quot; name=&quot;item1&quot; value=&quot;test&quot;/&gt;
&lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;Submit 1st form&quot;/&gt;
&lt;/form&gt;

&lt;form name=&quot;form2&quot;&gt;
&lt;input type=&quot;text&quot; name=&quot;item2&quot; value=&quot;test&quot;/&gt;
&lt;input type=&quot;submit&quot; name=&quot;submit&quot; value=&quot;Submit 2nd form&quot;/&gt;
&lt;/form&gt;
</pre>
Usually you would get POST variables &quot;item1&quot; and &quot;submit&quot; when submitting the 1st form and 
&quot;item2&quot; and &quot;submit&quot; when submitting the 2nd form. When submitting the form from PDF, you'll get 
&quot;form1_item1&quot;, &quot;form1_submit&quot; and &quot;form2_item2&quot;, &quot;form2_submit&quot; correspondingly.

</p>

<p>The name of the form is taken from &quot;name&quot; or &quot;id&quot; FORM tag attributes (note that if both attributes are specified, then
&quot;name&quot; have the higher priority). If both these attributes are missing, then the script attemts to generate an unique name for the form;
Newertheless, it is <strong>highly</strong> recommended to add &quot;id&quot; or &quot;name&quot; attributes for every form definition. The 
autogenerated form names may suddenly change when you change the page content. It is not guaranteed that future html2ps versions will 
use the same name generation rules.</p>

<p>Also, you must note that html2ps is less tolerant to the form definition than most browsers. You may get conversion errors or even
unpredictable results when viewing generated PDF if the following conditions are not satisfied:
<ul>
<li>Form names are unique throughout the page</li>
<li>Field names are unique in the form</li>
<li>Radio button values are unique inside the button group</li>
</ul>
</p>

<h3>Button field values</h3>
<p>
In HTML, when you click on the Submit button, the posted data will include the value of &quot;value&quot; attribute for the button. 
When you're submitting form from generated PDF, you'll get an <strong>empty string</strong> as a value of this parameter. Thus, 
this check is a bad idea (bad, but rather popular):
<pre class="code">
&hellip;
if ($_POST['my_submit_button_name']) { 
&hellip;
</pre>
and should be replaced by this code:
<pre class="code">
&hellip;
if (isset($_POST['my_submit_button_name'])) { 
&hellip;
</pre>
</p>

<h3>Image submit button click coordinates</h3>
<p>
In HTML forms, you'll get three POST varaibles after clicking on "image" submit button: &lt;button&gt;, &lt;button&gt;_x and &lt;button&gt;_y. 
When you're posting data from PDF you'll get only two last parameters!
</p>

<h3>Unsupported field types</h3>
<p>
&quot;file;&quot; and &quot;hidden&quot; fields are not supported.
</p>

<h2>Server-side form handling</h2>

<strong>Note:</strong> there's an PHP extension designed to work with FDF files; you may wish to check documentation at 
        PHP.net: <a title="Opens in new window" target="_blank" href="http://php.net/manual/en/ref.fdf.php">Forms Data Format Functions</a>

<p>Basically, you must use the script which accepts data in HTTP POST format and outputs result in FDF format. (Actually, in any format,
but be prepared to Acrobat Reader complaints like &quot;Cannot handle Content-Type: &hellip;&quot;)
The minimal data-handling example is:
<pre class="code">
// output an empty FPF file

$outfdf  = fdf_create();
$tmpname = tempnam('../temp',"FDF_");
fdf_set_status($outfdf, "Thank you!");
fdf_save($outfdf, $tmpname);
fdf_close($outfdf);

fdf_header();
$fp = fopen($tmpname, "r");
fpassthru($fp);
unlink($tmpname);
</pre>
It just confirms the receiving of the posted data; &quot;Thank you!&quot; message will be shown as a popup by Acrobat Reader. 
Probably you would want to actually do something with POSTed data, but is it far beyound the area of this manual.

<h2>Compatibility list</h2>
<table>
<thead>
<tr class="odd">
<th>Element</th>
<th>Is supported?</th>
<th>Notes</th>
</tr>
</thead>

<tbody>
<tr class="even">
<td>Text field (&lt;input type="text"&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="odd">
<td>Password field (&lt;input type="password"&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="even">
<td>Submit button (&lt;input type="submit"&gt;)</td>
<td class="yesno">Yes</td>
<td>Value of button "value" attribute is not posted</td>
</tr>

<tr class="odd">
<td>Reset button (&lt;input type="reset"&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="even">
<td>Plain button (&lt;input type="button"&gt;)</td>
<td class="yesno">Yes</td>
<td>Renders and you may click on them, but there's no much use of buttons, as Javascript is NOT supported</td>
</tr>

<tr class="odd">
<td>Checkbox (&lt;input type="checkbox"&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="even">
<td>Radio (&lt;input type="radio"&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="odd">
<td>Textarea (&lt;textarea&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="even">
<td>Select (&lt;select&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="odd">
<td>Image (&lt;input type="image"&gt;)</td>
<td class="yesno">Yes</td>
<td></td>
</tr>

<tr class="even">
<td>File (&lt;input type="file"&gt;)</td>
<td class="yesno">No</td>
<td></td>
</tr>

<tr class="odd">
<td>Hidden (&lt;input type="hidden"&gt;)</td>
<td class="yesno">No</td>
<td></td>
</tr>

</tbody>

</table>

</body>
</html>              
